Sketched an extension to also catch the wasm-emitted shape brif (ireduce.i32 (ctz.i64 X)) (and clz), which is what frontends like Motoko's moc produce — wasm's if takes an i32 condition, so the i64 LSB test always flows through ireduce and brif directly, with no icmp interposed for the egraph rules in this PR to match.

Scope creep: the natural place is each backend's is_nonzero helper (x64 inst.isle:3806-3826, aarch64 inst.isle:4659-4670, plus riscv64 and s390x), where rules like

(rule (is_nonzero (ctz val @ (value_type (ty_32_or_64 ty))))
  (CondResult.CC (x64_test ty val (RegMemImm.Imm 1)) (CC.Z)))

(rule (is_nonzero (clz val @ (value_type (ty_32_or_64 ty))))
  (CondResult.CC (x64_test ty val val) (CC.NS)))

would lower brif (ctz X) to test X, 1; jz and brif (clz X) to test X, X; jns directly, plus an (ireduce _ (ctz/clz _)) variant for the wasm path.

That's 4× backend files + filetests, different reviewers per arch, and a different review audience from this egraph PR. Punting on the amendment and filing a separate follow-up instead.

Concrete real-world workload for the clz boolean-context fold: Motoko's classical-persistence backend already emits the bare i32.clz; if shape for Int <-> 0 sign tests (e.g. Prim.abs). The compiler-side peephole (shrU 31; if -> clz; if(swap) and and 0x80000000; if -> clz; if(swap) in motoko/src/codegen/instrList.ml) generates this directly because their target is i32 wasm without a wrap.

So the JIT-side fold here is the natural meeting point for classical-Motoko output: clz directly into brif, no icmp, no ireduce. The rules in this PR don't yet catch that shape (it's brif (clz X), not icmp eq (clz X) 0), but the equivalent backend lowering (per the previous comment) would close that gap end-to-end.

Subscribe to Label Action

cc @cfallin, @fitzgen

Thanks for this! Are the backend rules necessary with the mid-end egraph rules? I'd expect that the egraph rewrites would be sufficient and the backends largely wouldn't need to change, unless they need to emit a new instruction pattern which isn't currently recognized.

One thing you may also want to do is to add something in tests/disas/*.wat. That's a wasm-level test which ensures that the right assembly will be generated which is a bit of an end-to-end test. Not required, but if you're curious that'd be a good way to validate that this is all kicking in correctly.

Added tests/disas/ctz-clz-bool-condition.wat (commit 0519796) per your suggestion — covers if/select/eqz consumers over (ctz/clz X) eq/ne 0 for i32 and i64, plus a numeric-comparison negative test ((ctz X) == 4).

Empirical answer to your first question — the egraph rules in this PR are complete for the icmp-mediated case but don't catch the wasm-natural bare form:

icmp-mediated (this PR's target — collapses correctly):

;; if_ctz_eq0_i32:        testl $1, %edx; jne
;; select_ctz_eq0_i32:    testl $1, %edx; cmovne
;; eqz_ctz_eq0_i32:       testl $1, %edx; sete
;; if_clz_eq0_i32:        testl %edx, %edx; jl

bare if (ctz X) (no icmp — what wasm frontends like Motoko emit directly):

;; if_ctz_bare_i32:       bsfl %edx, %r9d; cmovel; testl %r9d, %r9d; jne
;; if_clz_bare_i32:       bsrl + cmovel + 0x1f-sub + test  ;; 5 insns

negative test (correctly not collapsed — confirms the rules don't over-fire on numeric comparisons):

;; if_ctz_eq4_i32:        bsfl %edx, %r9d; cmpl $4, %r9d; je

So the egraph rules cover their intended shape end-to-end. The bare form would need backend is_nonzero specializations as a follow-up — happy to land this PR with just the egraph rules and tackle the bare form separately, if that scoping makes sense to you.